Cryptobionic system and associated devices and methods

ABSTRACT

Introduced here are cryptobionic implants designed for implantation within a human body that are capable of facilitating an identity authentication and/or an intent validation process. These cryptobionic implants can be designed to be cryptographically secure. For example, a cryptobionic implant may include a processor configured to encrypt data residing in an internal storage and a transponder configured to transmit the encrypted data to a reader device located outside of the human body for decryption. The reader device (or some other electronic device) may be able to verify the identity of the individual in whom the cryptobionic implant is implanted based on the decrypted data.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to U.S. Provisional Application No.62/685,640, titled “Cryptobionic System and Associated Methods” andfiled on Jun. 15, 2018, and U.S. application Ser. No. 16/443,387, titled“Cryptobionic System and Associated Devices and Methods” and filed onJun. 17, 2019, both are incorporated by reference herein in itsentirety.

TECHNICAL FIELD

Various embodiments concern techniques for authenticating the identityof individuals in whom transponders capable of performing cryptographicoperations have been implanted.

BACKGROUND

The concept of identity touches nearly every aspect of life in modernsociety, especially online activities. Every payment card in a wallet,every key on a keyring, and every credential for an account can beconsidered a token representative of identity. Each identity tokenrepresents the person that possesses it to a source. The source may be,for example, a door, vehicle, website, computer program, or entity suchas a merchant or bank. However, given how critical these identity tokensare, they are surprisingly insecure. This is especially true for accountcredentials (e.g., usernames and passwords) for websites and computerprograms accessible via the Internet.

Conventional challenges of identity normally involve a request foraccount credentials (e.g., by prompting the submittal of a username andpassword), or possibly a use of cryptographic token or an electronicdevice to produce an additional identification factor (often called“two-factor authentication”). One problem with these approaches is thelack of security for account credentials, as shown by the long historyof massive data breaches and account data compromises. Moreover,additional authentication factors tend to use technologies, such asmobile networks or cryptographic token exchanges, that can be vulnerableto subversion, loss, and theft.

BRIEF DESCRIPTION OF THE DRAWINGS

Various features of the technology will become more apparent to thoseskilled in the art from a study of the Detailed Description inconjunction with the drawings. Embodiments of the technology areillustrated by way of example and not limitation in the drawings, inwhich like references may indicate similar elements.

FIG. 1 illustrates how a transponder can be implanted within a humanbody.

FIG. 2 illustrates a network environment that includes a cryptobionicimplant capable of communicating with a reader device that iscommunicatively coupled to an identity service platform.

FIG. 3 depicts a flow diagram of a process for authenticating theidentity of an individual in whom a cryptobionic implant has beenimplanted.

FIG. 4 depicts a flow diagram of another process for authenticating theidentity of an individual in whom a cryptobionic implant has beenimplanted.

FIG. 5 depicts a flow diagram of a process that details how thetechnology described herein can be used as a replacement for passwordsor two-factor authentication.

FIG. 6 depicts a flow diagram of a process that details how thetechnology described herein can be used to perform “zero-click”authentication on a website.

FIG. 7 depicts a flow diagram of a process that details how thetechnology described herein can be used to complete a paymenttransaction.

FIG. 8 is a block diagram illustrating an example of a processing systemin which at least some operations described herein can be implemented.

The drawings depict various embodiments for the purpose of illustrationonly. Those skilled in the art will recognize that alternativeembodiments may be employed without departing from the principles of thetechnology. Accordingly, while specific embodiments are shown in thedrawings, the technology is amenable to various modifications.

DETAILED DESCRIPTION

Introduced here are cryptobionic implants designed for implantationwithin a human body that are capable of facilitating an identityauthentication process. The term “cryptobionic,” as used herein, refersto the ability to perform cryptographic processes within a living body,such as a human body or animal body. While embodiments may be describedin terms of identity authentication processes (also referred to as“identity verification processes”), those skilled in the art willrecognize that these implantable transponders may also be used tocomplete intent validation processes. Generally, an identityauthentication process will involve authenticating the identity of anindividual (e.g., based on data stored in a cryptobionic implant) andthen determining, based on the identity, whether the individual isauthorized to access a given resource, complete a given process, etc.Intent validation processes, meanwhile, may be akin to having anindividual confirm his/her intent. For example, if an individual wishesto log into his/her account with a financial institution, then theindividual may authenticate such action using a cryptobionic implant. Ifthe financial institution deems a transaction as abnormal, then theindividual may be prompted to validate the transaction by using thecryptobionic implant.

These cryptobionic implants (also referred to as “cryptobionic devices”)are designed to be cryptographically secure. For example, a cryptobionicimplant may include a processor configured to encrypt data and atransponder configured to transmit the encrypted data to a reader devicelocated outside of the human body for decryption by an identity serviceplatform. For example, the cryptobionic implant may receive data fromthe reader device via the transponder, hold the data in a memory atleast temporarily, encrypt the data with a cryptographic key, and thentransmit the encrypted data to the reader device. The data may berepresentative of a cryptographic challenge (or simply “challenge”) sentto the cryptobionic implant by the reader device, and the encrypted datamay be representative of a cryptographic response (or simply “response”)send to the reader device by the cryptobionic implant.

In some embodiments, data sent to the cryptobionic implant by the readerdevice may have been encrypted using a public cryptographic key (orsimply “public key”) associated with the cryptobionic implant. In suchembodiments, the cryptobionic implant can use a private cryptographickey (or simply “private key”) stored within its memory to decrypt thedata, and then the cryptobionic implant may send the decrypted data tothe reader device for authentication/validation purposes. Alternatively,the decrypted data may contain configuration changes for thecryptobionic implant. The data may also be cryptographically signed bythe cryptobionic implant, and the signature may need to be validatedbefore the data is honored. The signature can be checked by firsthashing the data and then checking the hash against a hash provided bythe signature.

The identity service platform may be able to verify the identity of theindividual in whom the cryptobionic implant is implanted based on thedata transmitted by the cryptobionic implant to the reader device. Theidentity service platform may reside on the reader device or some otherelectronic device that is communicatively connected to the readerdevice. Accordingly, a cryptobionic implant could be used to securedata, verify identity, and/or authorize transactions without the risk offorgetting or losing the cryptobionic implant.

A cryptobionic implant can work in concert with a computer program thatallows the cryptobionic implant to be easily and securely utilized forvarious activities. In some embodiments, the computer program resides onan electronic device associated with the individual in whom thecryptobionic implant is implanted. For example, the computer program mayreside on a mobile phone in the form of a mobile application. In otherembodiments, the computer program resides on an electronic deviceassociated with some other individual or entity. For example, thecomputer program may reside on a card reader associated with a merchantwith whom the individual would like to complete a transaction. Thecomputer program may be supported by an identity service platformdesigned to facilitate interactions between cryptobionic implants andthird parties through application programming interfaces (APIs).

As noted above, each cryptobionic implant may include a transpondercapable of communicating with electronic devices located in closeproximity. The transponder may be a near-field communication (NFC)standards-compliant transponder having an antenna capable ofcommunicating with the communication interface of a reader device thatresides outside of the human body. As further described below, toinitiate communication, the individual may place the cryptobionicimplant near the communication interface of the reader device. Someembodiments of the transponder include an antenna capable ofcommunicating via active radio-frequency identification (RFID). In suchembodiments, the cryptobionic implant may include a power source (e.g.,a battery) that allows the antenna to periodically or continuallytransmit data. Other embodiments of the transponder include an antennacapable of communicating via passive RFID. Passive transponders maycommunicate with a reader device via a magnetic field, a capacitivecoupling, or an electromagnetic field. In such embodiments, the antennamay be a tuned inductor coil that is used by the transponder to inductpower from the magnetic field and/or modulate the magnetic field tocommunicate data. A transponder could be designed to communicate onlywith the identity service platform (also referred to as an “identityclearinghouse”) to authenticate an individual, authorize transactions,and/or verify the identity of the individual—either online or in person.

Embodiments may be described with reference to particular computerprograms, communication protocols, networks, etc. However, those skilledin the art will recognize that the features of these embodiments areequally applicable to other computer program types, communicationprotocol types, network types, etc. Moreover, the technology can beembodied using special-purpose hardware (e.g., circuitry), programmablecircuitry appropriately programmed with software and/or firmware, or acombination of special-purpose hardware and programmable circuitry.Accordingly, embodiments may include a machine-readable medium havinginstructions that may be used to program an electronic device to receiveinput indicative of a request from a third-party service to submit acryptographic challenge to a cryptobionic implant, transmit acryptographic challenge to the transponder of the cryptobionic implantover a short-range communication protocol, receive a response to thecryptographic challenge from the cryptobionic implant, and then returnthe response (or data representative of the response) to the third-partyservice.

Terminology

References to “an embodiment” or “one embodiment” means that theparticular feature, function, structure, or characteristic beingdescribed is included in at least one embodiment. Occurrences of suchphrases do not necessarily refer to the same embodiment, nor are theynecessarily referring to alternative embodiments that are mutuallyexclusive of one another.

The terms “connected,” “coupled,” or any variant thereof is intended toinclude any connection/coupling between two or more elements, eitherdirect or indirect. The connection/coupling can be physical, logical, ora combination thereof. For example, components may be electrically orcommunicatively coupled to one another despite not sharing a physicalconnection.

The term “based on” is to be construed in an inclusive sense rather thanan exclusive or exhaustive sense. Thus, unless otherwise noted, the term“based on” is intended to mean “based at least in part on.”

When used in reference to a list of multiple items, the word “or” isintended to cover all of the following interpretations: any of the itemsin the list, all of the items in the list, and any combination of itemsin the list.

The sequences of steps performed in any of the processes described hereare exemplary. However, unless contrary to physical possibility, thesteps may be performed in various sequences and combinations. Forexample, steps could be added to, or removed from, the processesdescribed here. Similarly, steps could be replaced or reordered. Thus,descriptions of any processes are intended to be open-ended.

Technology Overview

FIG. 1 illustrates how a transponder 102 can be implanted within a humanbody. Here, the transponder 102 is part of an implant 104 withcryptographic processing capabilities that has been implanted into theleft hand 106 of the human body. In particular, the cryptobionic implant104 (also referred to as a “cryptobionic implant”) has been sub-dermallyimplanted into the fascia tissue between the dermis and muscle in theleft hand 106.

The cryptobionic implant 104 could be implanted in other parts of thehuman body, however. The location of the cryptobionic implant 104 isgenerally not important, through placement between the first and secondmetacarpal bones of either hand offers several advantages. In thislocation, the cryptobionic implant 104 can be easily placed near areader device 108 that is secured in a particular location. The readerdevice 108 is an electronic device capable of communicating with thetransponder 102 of the cryptobionic implant 104. One example of a readerdevice is a card reader that can be used by a merchant to scan paymentcards (e.g., credit cards and debit cards). Another example of a readerdevice is an access control terminal that limits access to a physicalenvironment (e.g., by controlling the lock of a door). Other examples ofreader devices include mobile phones, wearable electronic devices (e.g.,watches and fitness trackers), laptop computers, etc. If the readerdevice 108 is a mobile phone or wearable electronic device, then thelocation of the cryptobionic implant 104 is less critical as the readerdevice 108 can be easily placed near the cryptobionic implant 104.

The transponder 102 may be a radio-frequency identification (RFID)transponder capable of communicating with the reader device 108 usingelectromagnetic fields. As further described below, the reader device108 can be configured to automatically identify the cryptobionic implant104 (and thus the individual in whom the cryptobionic implant 104 isimplanted) based on a response emitted by the transponder 102 inresponse to a challenge emitted by the reader device 108. This exchangeof data may be performed in accordance with a short-range communicationprotocol, such as Bluetooth®, near-field communication (NFC), Zigbee®,or a proprietary point-to-point communication protocol. Accordingly, thetransponder 102 may be a cryptographically-secure, NFC-complianttransponder that can be used for identification, authentication, etc.

FIG. 2 illustrates a network environment 200 that includes acryptobionic implant 202 capable of communicating with a reader device204 that is communicatively coupled to an identity service platform 206.The identity service platform 206 may be responsible for validating theidentify of a person in whom the cryptobionic implant 202 is implantedbased on signals emitted by the cryptobionic implant 202 that aredetected by the reader device 204. The identity service platform 206 mayalso be responsible for creating interfaces through which individualscan connect third-party services/systems to the identity serviceplatform 206, manage preferences, etc.

The identity service platform 206 may be designed such that anindividual can communicatively couple a third-party service/system tothe identity service platform 206 through an application programminginterface (API). For example, the identity service platform 206 maysupport APIs associated with OAuth 2.0, OpenID Connect, SAML 2.0Authentication single sign-on (SSO), and Shibboleth, as well asproprietary APIs The individual may be associated with the third partyor the identity service platform 206. Through the API, the third-partyservice/system can seamlessly communicate with the identity serviceplatform 206.

Imagine, for example, that an individual is interested in completing atransaction with a merchant at a physical storefront. The individual mayattempt to complete the transaction by presenting a payment card (e.g.,a credit card or debit card) to a payment processing system of themerchant. Thereafter, the payment processing system may send informationregarding the transaction to a financial institution for review. Apayment authorization system associated with the financial institutionmay be communicatively coupled to the identity service platform 206through a dedicated API accessible only to the payment authorizationsystem. As part of the transaction, the purchaser may be prompted toscan his/her cryptobionic implant at a reader device (e.g., a cardreader managed by the merchant, or a mobile phone associated with thepurchaser). The reader device 204 can transmit cryptographically-securedata indicative of the cryptobionic implant 202 to the identity serviceplatform 206, and then the identity service platform 206 can transmit anindication of authentication to the payment authorization system of thefinancial institution via the API. The payment authorization system candetermine whether to approve payment for the transaction based on theindication of authentication received from the identity service platform206.

As another example, an individual may be interested in completing atransaction with a merchant through a digital storefront. The individualmay attempt to complete the transaction by entering details regarding apayment card into a website for transmittal to a payment processingsystem of the merchant. Thereafter, the payment processing system maysend information regarding the transaction to a financial institutionfor review. A payment authorization system associated with the financialinstitution may be communicatively coupled to the identity serviceplatform 206 through a dedicated API accessible only to the paymentauthorization system. As part of the transaction, the purchaser may beprompted to scan his/her cryptobionic implant using a mobile phone onwhich the identity service platform 206 resides in the form of a mobileapplication. The identity service platform 206 can transmit anindication of authentication to the payment authorization system of thefinancial institution via the API. The payment authorization system candetermine whether to approve payment for the transaction based on theindication of authentication received from the identity service platform206.

As noted above, the cryptobionic implant 202, reader device 204, andidentity service platform 206 (collectively referred to as the“networked components”) may reside in a network environment 200. Thus,the networked components may be connected to one or more networks 208a-b. The network(s) 208 a-b can include personal area networks (PANs),local area networks (LANs), wide area networks (WANs), metropolitan areanetworks (MANs), cellular networks, the Internet, etc. Additionally oralternatively, the networked components can be communicatively coupledto one another over a short-range communication protocol, such asBluetooth®, NFC, Zigbee®, or a proprietary point-to-point communicationprotocol. For example, the cryptobionic implant 202 and the readerdevice 204 may communicate with one another via NFC, while the readerdevice 204 and the identity service platform 206 may be communicate withone another via the Internet.

Interfaces created and/or supported by the identity service platform 206may be accessible via a digital service which could be embodied by a webbrowser, desktop application, mobile application, or over-the-top (OTT)application, or other similar embodiments. Accordingly, the interfacesmay be viewed on a laptop computer, tablet computer, personal digitalassistant (PDA), mobile phone, game console, music player, wearableelectronic device (e.g., a watch or fitness accessory),network-connected (“smart”) electronic device, (e.g., a television orhome assistant device), virtual/augmented reality system (e.g., ahead-mounted display), or some other electronic device.

Some embodiments of the identity service platform 206 can be hostedlocally. That is, the identity service platform 206 may reside on thereader device 204. For example, the identity service platform 206 may beembodied as a mobile application executing on a mobile phone that servesas the reader device 204. As another example, the identity serviceplatform 206 may be embodied as a software plug-in that resides on acard reader or an access control terminal that serves as the readerdevice 204. Other embodiments of the identity service platform 206 areexecuted by a cloud computing service operated by Amazon Web Services®(AWS), Google Cloud Platform™, Microsoft Azure®, or a similartechnology. In such embodiments, the identity service platform 206 mayreside on a computer server that is accessible to the reader device 204across a network 208 a.

FIG. 3 depicts a flow diagram of a process for authenticating theidentity of an individual in whom a cryptobionic implant 300 has beenimplanted. In particular, FIG. 3 illustrates how a third-party servicecan communicate with an identity service platform responsible forverifying the identity of the individual. While the process of FIG. 3 isdescribed in terms of a third-party service for the purpose ofillustration, those skilled in the art will recognize that thetechnology is equally applicable to third-party systems. Examples ofthird-party systems include database systems, payment processingsystems, permission verification systems, etc.

Initially, a service associated with a third party can submit a requestfor identity authentication and/or intent validation over a network suchas the Internet (step 1). For example, the third-party service 308 maysubmit a request to an identity service platform 306 via an API. In someembodiments, the API is a dedicated API accessible only to thethird-party service 308. In such embodiments, the identity serviceplatform 306 may be accessible via multiple APIs, and each API of themultiple APIs may be associated with a different third-party service.The request may include information associated with the third-partyservice 308, the individual in whom the cryptobionic implant 300 isimplanted, the nature of the service being rendered, etc. The terms“third-party service” and “external service” refer to a digital serviceother than the identity service platform 306 itself.

The identity service platform 306 can then forward the request (or dataindicative of the request) to a reader device 304 (step 2). For example,upon receiving the request from the third-party service 308, theidentity service platform 306 may store information regarding therequest in a memory and then generate a notification to be transmittedto the reader device 304. Upon receiving the notification, the readerdevice 304 may prompt the individual to validate the request by placingthe cryptobionic implant 300 near a communication interface 302. Thecommunication interface 302 may be attached to, or embedded within, thereader device 304. One example of a communication interface 302 is anNFC radio interface.

When the cryptobionic implant 300 is placed near the communicationinterface 302 of the reader device 304, the reader device 304 caninterrogate the cryptobionic implant 300. For example, the reader device304 may transmit inquiry data in the form of interrogating radio wavesto the cryptobionic implant 300 (step 3), and then the cryptobionicimplant 300 may respond by transmitting identity data in the form ofresponding radio waves to the reader device 304 (step 4). The readerdevice 304 can then send at least a portion of the identity data to theidentity service platform 306 for authentication (step 5).

In some instances, the cryptobionic implant 300 may not hold anyidentity data. In such embodiments, the cryptobionic implant 300 maysimply need to be cryptographically proven to be authentic, and allidentity data could be hosted on the identity service platform 306(e.g., in profiles associated with different cryptobionic implants,individuals, etc.). For example, data may be sent to the cryptobionicimplant 300 by the reader device 304 may have been encrypted using apublic key. The data may have been encrypted by the identity serviceplatform 306 using a public key stored in a profile associated with thecryptobionic implant 300 or individual. The profile could be associatedwith one or more cryptobionic implants implanted within thecorresponding individual. The cryptobionic implant 300 can use a privatekey stored within its memory to decrypt the data, and then thecryptobionic implant 300 may send the decrypted data to the readerdevice 304 for authentication/validation purposes. The data may also becryptographically signed by the cryptobionic implant 300 and/or identityservice platform 306, and the signature may need to be validated beforethe data is honored. The signature can be checked by first hashing thedata and then checking the hash against a hash provided by thesignature.

At this point, the identity service platform 306 and cryptobionicimplant 300 may begin communicating with each other through the readerdevice 304 using secure cryptograms until the cryptobionic implant 300is able to cryptographically prove that it is legitimate. Said anotherway, the identity service platform 306 and cryptobionic implant 300 maycryptographically communicate with one another until the identityservice platform 306 can establish that the cryptobionic implant 300 islegitimate (i.e., is not an unauthorized entity attempting toemulate/mimic the cryptobionic implant 300).

After the identity service platform 306 has established that thecryptobionic implant 300 is legitimate, the identity service platform306 can consider the request for identity authentication and/or intentvalidation as having been approved. The identity service platform 306can then transmit a message representative of an approval of the requestfor identity authentication and/or intent validation to the third-partyservice 308 (step 6). Alternatively, if the individuals fails to scanthe cryptobionic implant 300 properly or opts not to scan thecryptobionic implant 300, then the identity service platform 306 cantransmit an error message to the third-party service 308. In suchembodiments, the third-party service 308 may choose not to perform anyfurther actions on behalf of the individual. For example, as furtherdescribed below, the third-party service 308 may opt to restrict accessto a website, disapprove a payment transaction, etc.

FIG. 4 depicts a flow diagram of another process for authenticating theidentity of an individual in whom a cryptobionic implant 400 has beenimplanted. Here, however, the request for identity authentication issubmitted by a third-party computer program 408 executing on the readerdevice 404. The third-party computer program may be a desktopapplication, mobile application, or OTT application.

Initially, the third-party computer program 408 may instruct the readerdevice 404 to interrogate the cryptobionic implant 400 (step 1). Forexample, the third-party computer program 408 may submit a request forone or more cryptographic public keys hosted on the cryptobionic implant400 to a processor 406 of the reader device 404. The processor 406 canthen forward the request (or data indicative of the request) to thecryptobionic implant 400 via a communication interface 402 (step 2). Thecommunication interface 402 may be attached to, or embedded within, thereader device 404. One example of a communication interface 402 is anNFC radio interface.

Upon receiving the request, the cryptobionic implant 400 can generate aresponse that includes the cryptographic public key(s), and then thecryptobionic implant 400 can transmit the response to the processor 406of the reader device 404 using the communication interface 402 (step 3).In some embodiments, the processor 406 stores the cryptographic publickey(s) in a database structure maintained within a storage accessible tothe reader device 404. The processor 406 can maintain a list ofauthorized cryptobionic implants by updating the log as cryptographicpublic keys are received by cryptobionic implants over time. As shown inFIG. 4, the processor 406 can then provide the cryptographic publickey(s) to the third-party computer program 408 (step 4). Alternatively,the processor 406 may send a notification to the third-party computerprogram 408 that indicates the cryptographic public key(s) wereretrieved as requested. Receipt of the notification or the cryptographicpublic key(s) may be sufficient for the third-party computer program 408to consider the identity of the individual in whom the cryptobionicimplant 400 has been implanted as verified.

Imagine, for example, that an individual wishes to enroll a cryptobionicimplant with a lock (e.g., for a door) to enable access control. Thelock (or access control system that is communicatively connected to thelock) needs to know the public key associated with the cryptobionicimplant so that it can generate an appropriate challenge. In anenrollment scenario, the lock wants to get the public key from thecryptobionic implant, so the lock may be set in a “learning mode” suchthat the public key can be learned upon scanning of the cryptobionicimplant. When the individual scans the cryptobionic implant, the lockwill ask the cryptobionic implant for its public key, and thecryptobionic implant will provide the public key in a format that issigned (e.g., the public key itself may be hashed, and the hash may besigned using the private key corresponding to the public key). Uponreceiving the public key, the lock can check the signature to ensure thesender has possession of the corresponding private key.

Thereafter, when the individual approaches the lock and presents thecryptobionic implant, the lock will get the public key from thecryptobionic implant, compare the public key to a list (e.g., hosted onthe lock or the identity service platform), and then determine whetherthe individual should be allowed entry based the comparison. Inparticular, the lock may send a challenge to the cryptobionic implant,and the cryptobionic implant may sign the challenge with the private keyand send the signed challenge back as the response. The lock can checkwhether the signature is valid using the public key received during theenrollment process. If the signature is determined to be valid, the lockcan permit access.

FIG. 5 depicts a flow diagram of a process 500 that details how thetechnology described herein can be used as a replacement for passwordsor as part of a two-factor authentication procedure. Here, the process500 is described in the context of validating identity upon logging intoa website. However, those skilled in the art will recognize that thetechnology is equally applicable in other scenarios.

Initially, an individual may access a website using a web browser thatis executing on an electronic device (step 501). The electronic devicemay be, for example, a laptop computer, mobile phone, head-mounteddisplay, or wearable electronic device such as a watch or fitnessaccessory. The individual may authenticate himself/herself using atleast a portion of a set of credentials associated with an account forthe website (step 502). In some embodiments, the individual may input ausername and password. In other embodiments, the individual may onlyinput a username. In such embodiments, the individual may rely on thecryptobionic implant to act as the “password” for the account.

After the credentials have been submitted, the computer server (alsoreferred to as a “web server”) responsible for supporting the websitecan determine whether the account is associated with a profile for anidentity service platform. The computer server may determine whether theaccount has been linked with the profile through, for example, standardmeans such as OAuth 2.0, OpenID Connect, a proprietary authorizationprotocol, SAML 2.0 Authentication single sign-on (SSO), Shibboleth, etc.OAuth 2.0 is a standard authorization protocol, while OpenID Connect isan identity layer on top of OAuth 2.0 that allows a client (e.g., thecomputer server) to access and verify the identity data of a user (e.g.,the individual) based on authentication performed by a separateauthorization computer server. The identity data could include detailssuch as name, physical address, email address, etc. In response todetermining that the account has been linked with the profile, thecomputer server can make a call to an API of the identity serviceplatform (step 503). The call may be representative of an authenticationrequest in which the computer server provides a token that identifiesthe linked profile. In some embodiments the token is generated by thecomputer server based on a format specified by the identity serviceplatform, while in other embodiments the token is a token that waspreviously received from the identity service platform. The token may bein a predetermined format that has been agreed upon by the computerserver and identity service platform.

The identity service platform can then send a notification to theelectronic device with information regarding the authentication request(step 504). For example, the notification may specify the name of thewebsite, the username of the account requiring authentication, etc. Uponreceiving the notification from the identity service platform, theelectronic device may instruct the individual to present his/hercryptobionic implant to the communication interface to validate theauthentication request (step 505). As noted above, the communicationinterface may be affixed to, or embedded within, the electronic device.Thereafter, the individual can present the cryptobionic implant to thecommunication interface of the electronic device (step 506).

Completion of such action may permit the identity service platform tocommunicate with the cryptobionic implant. In some embodiments, theidentity service platform communicates directly with the cryptobionicimplant (e.g., via the Internet). In other embodiments, the identityservice platform communicates indirectly with the cryptobionic implant(e.g., via the electronic device). As part of the authenticationprocess, the identity service platform may present a question (alsoreferred to as a “challenge”) to which the cryptobionic implant mustprovide a valid answer (also referred to as a “response”) in order to beauthenticated (step 507). Accordingly, the identity service platform mayissue a challenge that requires the cryptobionic implant employcryptographic processing while in the human body.

After processing the challenge (step 508), the cryptobionic implant cangenerate a response (step 509). To generate the response, thecryptobionic implant may encrypt data (e.g., cryptographic public keys)stored within storage of the cryptobionic implant. The cryptobionicimplant can transmit the response to the communication interface of theelectronic device, which forwards the response to the identity serviceplatform where it is cryptographically validated (step 510). Forexample, the identity service platform may decrypt the response using acryptographic key associated with the cryptobionic implant, theindividual, the computer server, the third-party service associated withthe computer server, or any combination thereof. After the identityservice platform has confirmed the response is legitimate, the identityservice platform can provide a response to the call placed by thecomputer service through the API (step 511). For example, the identityservice platform may send a response to the computer server thatindicates the authentication was successful. Upon receiving the responsefrom the identity service platform, the computer server can deem theindividual authenticated and allow the individual to access the website(step 512).

FIG. 6 depicts a flow diagram of a process 600 that details how thetechnology described herein can be used to perform “zero-click”authentication on a website. The website may be associated with afinancial institution (e.g., a bank or investment firm), insuranceprovider, accounting firm, law firm, government agency (e.g., theInternal Revenue Service or a department of motor vehicles), or someother entity that handles sensitive information. Initially, theindividual links his/her account for a website with a profile for anidentity service platform (step 601). The individual may link theaccount and profile through, for example, standard means such as OAuth2.0, OpenID Connect, or a proprietary authorization protocol.

Thereafter, when the individual accesses the website using a web browserthat is executing on an electronic device (step 602), the computerserver (also referred to as a “web server”) responsible for supportingthe website can read a Hypertext Transfer Protocol (HTTP) cookie (alsoreferred to as a “web cookie,” “Internet cookie,” “browser cookie,” orsimply “cookie”) storing during a previous visit to the website (step603). The cookie may include (or refer to) a token that was previouslyacquired upon completing an authorization procedure or anaccount-linking procedure. One example of an authorization procedure isprocess 500 of FIG. 5. The computer server can then make a call to anAPI of the identity service platform (step 604). The call may berepresentative of an authentication request in which the computer serverprovides the token that identifies the linked profile.

Steps 604-613 of FIG. 6 may be similar to steps 503-512 of FIG. 5.Accordingly, once the authentication process has been successfullycompleted by the identity service platform, the web server may permitthe individual to access the website without manually entering anycredentials.

FIG. 7 depicts a flow diagram of a process 700 that details how thetechnology described herein can be used to complete a paymenttransaction. Although the process 700 is described in the context of apayment transaction conducted in a digital storefront through a websiteaccessible on an electronic device, those skilled in the art willrecognize that the process 700 is equally applicable to paymenttransactions conducted in physical storefronts. In such a scenario, theindividual may be prompted to present his/her cryptobionic implant tothe communication interface of a card reader rather than theindividual's own electronic device.

Initially, the individual links an account for a financial institutionwith a profile for an identity service platform (step 701). Theindividual may link the account and profile through, for example,standard means such as OAuth 2.0, OpenID Connect, or a proprietaryauthorization protocol. Thereafter, the individual may attempt tocomplete a purchase of an item through a website associated with amerchant (step 702).

In some instances, the financial institution may suspect fraud uponreceiving a request to transfer payment from the individual to themerchant (step 703). The financial institution may suspect fraud if theindividual has not purchased any items from the merchant before, if theindividual and merchant are located in different countries, if themerchant is on a list of potentially fraudulent merchants, etc. In suchembodiments, the financial institution can make a call to an API of theidentity service platform (step 704). For example, an electronic devicemanaged by the financial institution, such as a payment processingsystem or database system, can make a call to a dedicated API accessibleonly to the financial institution. The call may be representative of anauthentication request in which the financial institution provides atoken that identifies the linked profile for the identity serviceplatform. The call may also include information regarding the paymenttransaction, such as the name of the merchant, the location of themerchant, the time, the payment amount, etc. The token may be in aformat agreed upon by the financial institution and identity serviceplatform.

The identity service platform can then send a notification to a readerdevice with information regarding the authentication request (step 705).The notification may specify the name of the merchant, the paymentamount, or other relevant data. Upon receiving the notification from theidentity service platform, the reader device may instruct the individualto present the cryptobionic implant to the communication interface tovalidate the authentication request (step 706). As noted above, thereader device may take different forms depending on the type of paymenttransaction. For example, if the payment transaction is conducted in adigital storefront, then an electronic device associated with theindividual may instruct the individual to present the cryptobionicimplant for authentication purposes (store 707). The electronic devicemay be a laptop computer, mobile phone, head-mounted display, orwearable electronic device such as a watch or fitness accessory. If thepayment transaction is conducted in a physical storefront, however, thenthe instructions may be provided by an electronic device associated withthe individual, an electronic device associated with the merchant, orsome combination thereof. For example, a card reader associated with themerchant may instruct the individual to present the cryptobionic implantto the card reader for authentication purposes. As another example, amobile phone associated with the individual may instruct the individualto present the cryptobionic implant to the mobile phone forauthentication purposes. As another example, the mobile phone associatedwith the individual may instruct the individual to present thecryptobionic implant to the card reader for authentication purposes.

Steps 708-712 of FIG. 7 may be substantially similar to steps 507-511 ofFIG. 5. Accordingly, once the authentication process has beensuccessfully completed by the identity service platform, the financialinstitution may approve the payment transaction and then transferpayment to the merchant (step 713).

Unless contrary to physical possibility, it is envisioned that the stepsdescribed above may be performed in various sequences and combinations.For example, some embodiments of the cryptobionic implant may includeactive transponders that periodically emit signals in an attempt toestablish a connection with the antennas of nearby reader devices. Otherembodiments of the cryptobionic implant include passive transpondersthat only emit signals in response to being scanned by the antenna of anearby reader device.

Other steps may also be included in some embodiments. For example, theidentity service platform may be configured to store data received froma cryptobionic implant in a profile associated with the cryptobionicimplant, the individual in whom the cryptobionic implant is implanted,the third-party service requesting authentication of the individual, orany combination thereof.

The technology described herein provides several advantages, such as theeasy, secure, and effective transfer of critical data necessary forauthorizing identity from vulnerable electronic devices (e.g., mobilephones and laptop computers) into in vivo implants in a frictionless,management-free, and cryptographically-secure manner. For instance,private cryptographic keys can be readily transferred into the moresecure, controllable environment offered by in vivo implants.Additionally, the technology can employ procedures that ensure anindividual could use any electronic device, even those associated withfriends, family members, or strangers, without fear that the electronicdevice might obtain sensitive information that could be used torepresent the individual to another service/system. In effect, theelectronic device becomes a simple data pipe that connects the implantto the identity service platform and, by proxy, with any third-partyservices/systems connected to the identity service platform. Athird-party service/system may wish to request cryptographic validationof an authentication, authorization of a transaction, or confirmation ofan identity.

In some embodiments, the technology elevates the individual from asimply collection of tokens representative of identity, such as keys,cards, or credentials. The cryptobionic implant, by its very nature,augments the individual with cryptographic capabilities. Together withthe identity service platform, the cryptographic implant allows thesecapabilities to be easily and effectively employed such that theindividual can cryptographically represent himself/herself. Accordingly,the focus of identity authorization can return to real people ratherthan their tokens.

Processing System

FIG. 8 is a block diagram illustrating an example of a processing system800 in which at least some operations described herein can beimplemented. For example, components of the processing system 800 may behosted on a cryptobionic implant, a reader device that iscommunicatively coupled to the cryptobionic implant, an electronicdevice that includes an identity service platform, or distributedtherebetween.

The processing system 800 may include one or more central processingunits (“processors”) 802, main memory 806, non-volatile memory 810,network adapter 812 (e.g., network interface), video display 818,input/output devices 820, control device 822 (e.g., keyboard andpointing devices), drive unit 824 including a storage medium 826, andsignal generation device 830 that are communicatively connected to a bus816. The bus 816 is illustrated as an abstraction that represents one ormore physical buses and/or point-to-point connections that are connectedby appropriate bridges, adapters, or controllers. The bus 816,therefore, can include a system bus, a Peripheral Component Interconnect(PCI) bus or PCI-Express bus, a HyperTransport or industry standardarchitecture (ISA) bus, a small computer system interface (SCSI) bus, auniversal serial bus (USB), IIC (I2C) bus, or an Institute of Electricaland Electronics Engineers (IEEE) standard 1394 bus (also referred to as“Firewire”).

The processing system 800 may share a similar computer processorarchitecture as that of a desktop computer, tablet computer, personaldigital assistant (PDA), mobile phone, game console, music player,wearable electronic device (e.g., a watch or fitness tracker),network-connected (“smart”) device (e.g., a television or home assistantdevice), virtual/augmented reality systems (e.g., a head-mounteddisplay), or another electronic device capable of executing a set ofinstructions (sequential or otherwise) that specify action(s) to betaken by the processing system 800.

While the main memory 806, non-volatile memory 810, and storage medium826 (also called a “machine-readable medium”) are shown to be a singlemedium, the term “machine-readable medium” and “storage medium” shouldbe taken to include a single medium or multiple media (e.g., acentralized/distributed database and/or associated caches and servers)that store one or more sets of instructions 828. The term“machine-readable medium” and “storage medium” shall also be taken toinclude any medium that is capable of storing, encoding, or carrying aset of instructions for execution by the processing system 800.

In general, the routines executed to implement the embodiments of thedisclosure may be implemented as part of an operating system or aspecific application, component, program, object, module, or sequence ofinstructions (collectively referred to as “computer programs”). Thecomputer programs typically comprise one or more instructions (e.g.,instructions 804, 808, 828) set at various times in various memory andstorage devices in a computing device. When read and executed by the oneor more processors 802, the instruction(s) cause the processing system800 to perform operations to execute elements involving the variousaspects of the disclosure.

Moreover, while embodiments have been described in the context of fullyfunctioning computing devices, those skilled in the art will appreciatethat the various embodiments are capable of being distributed as aprogram product in a variety of forms. The disclosure applies regardlessof the particular type of machine or computer-readable media used toactually effect the distribution.

Further examples of machine-readable storage media, machine-readablemedia, or computer-readable media include recordable-type media such asvolatile and non-volatile memory devices 810, floppy and other removabledisks, hard disk drives, optical disks (e.g., Compact Disk Read-OnlyMemory (CD-ROMS), Digital Versatile Disks (DVDs)), and transmission-typemedia such as digital and analog communication links.

The network adapter 812 enables the processing system 800 to mediatedata in a network 814 with an entity that is external to the processingsystem 800 through any communication protocol supported by theprocessing system 800 and the external entity. The network adapter 812can include a network adaptor card, a wireless network interface card, arouter, an access point, a wireless router, a switch, a multilayerswitch, a protocol converter, a gateway, a bridge, bridge router, a hub,a digital media receiver, and/or a repeater.

The network adapter 812 may include a firewall that governs and/ormanages permission to access/proxy data in a computer network, andtracks varying levels of trust between different machines and/orapplications. The firewall can be any number of modules having anycombination of hardware and/or software components able to enforce apredetermined set of access rights between a particular set of machinesand applications, machines and machines, and/or applications andapplications (e.g., to regulate the flow of traffic and resource sharingbetween these entities). The firewall may additionally manage and/orhave access to an access control list that details permissions includingthe access and operation rights of an object by an individual, amachine, and/or an application, and the circumstances under which thepermission rights stand.

The techniques introduced here can be implemented by programmablecircuitry (e.g., one or more microprocessors), software and/or firmware,special-purpose hardwired (i.e., non-programmable) circuitry, or acombination of such forms. Special-purpose circuitry can be in the formof one or more application-specific integrated circuits (ASICs),programmable logic devices (PLDs), field-programmable gate arrays(FPGAs), etc.

REMARKS

The foregoing description of various embodiments of the claimed subjectmatter has been provided for the purposes of illustration anddescription. It is not intended to be exhaustive or to limit the claimedsubject matter to the precise forms disclosed. Many modifications andvariations will be apparent to one skilled in the art. Embodiments werechosen and described in order to best describe the principles of theinvention and its practical applications, thereby enabling those skilledin the relevant art to understand the claimed subject matter, thevarious embodiments, and the various modifications that are suited tothe particular uses contemplated.

Although the Detailed Description describes certain embodiments and thebest mode contemplated, the technology can be practiced in many ways nomatter how detailed the Detailed Description appears. Embodiments mayvary considerably in their implementation details, while still beingencompassed by the specification. Particular terminology used whendescribing certain features or aspects of various embodiments should notbe taken to imply that the terminology is being redefined herein to berestricted to any specific characteristics, features, or aspects of thetechnology with which that terminology is associated. In general, theterms used in the following claims should not be construed to limit thetechnology to the specific embodiments disclosed in the specification,unless those terms are explicitly defined herein. Accordingly, theactual scope of the technology encompasses not only the disclosedembodiments, but also all equivalent ways of practicing or implementingthe embodiments.

The language used in the specification has been principally selected forreadability and instructional purposes. It may not have been selected todelineate or circumscribe the subject matter. It is therefore intendedthat the scope of the technology be limited not by this DetailedDescription, but rather by any claims that issue on an application basedhereon. Accordingly, the disclosure of various embodiments is intendedto be illustrative, but not limiting, of the scope of the technology asset forth in the following claims.

What is claimed is:
 1. A computer-implemented method comprising: receiving, by an identity service platform, a request to authenticate an individual from an digital service; transmitting, by the identity service platform, an instruction to interrogate an implant located in the individual to a reader device, wherein upon receiving the instruction, the reader device may or may not instruct the individual to place the implant near the reader device; receiving, by the identity service platform, a response to the interrogation of the implant from the reader device; determining, by the identity service platform based on the response, that the individual should be authenticated; storing, by the identity service platform, the response in a profile associated with the implant, the individual, the digital service, or any combination thereof; and transmitting, by the identity service platform, a message indicating that the request was completed to the requesting service.
 2. The computer-implemented method of claim 1, further comprising: decrypting, or validating the cryptographic signature of, by the identity service platform, the response using a cryptographic key associated with the implant, the individual, the external service, or any combination thereof.
 3. The computer-implemented method of claim 1, wherein the request is received from the external service through an application programming interface (API).
 4. The computer-implemented method of claim 3, wherein the API is a dedicated API accessible only to the external service.
 5. The computer-implemented method of claim 3, wherein the API is one of multiple APIs through which the identity service platform can receive requests from external services, and wherein each API of the multiple APIs is associated with a different external service.
 6. The computer-implemented method of claim 1, wherein the instruction to interrogate the implant is transmitted to the reader device across the Internet.
 7. The computer-implemented method of claim 1, wherein the response includes a cryptographic key.
 8. A method for performing two-factor authentication, the method comprising: allowing, by an electronic device, an individual to access a digital service; receiving, by the electronic device, input from the individual indicative of credentials for the service, wherein the credentials are associated with an account for the service; receiving, by the electronic device, a request to authenticate the individual from an identity service platform that is communicatively coupled to the service; instructing, by the electronic device, the individual to place an implant in proximity of the electronic device; transmitting, by the electronic device, a challenge to the implant; receiving, by the electronic device, a response to the challenge from the implant, wherein the response includes data encrypted by implant in response to receiving the challenge; and providing, by the electronic device, the response to the identity service platform responsible for determining whether to authenticate the individual based on the encrypted data, wherein upon receiving the response, the identity service platform stores the response in a profile associated with the implant, the individual, the digital service, or any combination thereof.
 9. The method of claim 8, wherein said providing comprises: transmitting the challenge from the identity service platform and the response to the identity service platform across a digital communication medium. 